fix(ci): add sleep between service enablement and resource creation#5444
fix(ci): add sleep between service enablement and resource creation#5444haphungw wants to merge 2 commits intogoogleapis:mainfrom
Conversation
dbolduc
left a comment
dbolduc
left a comment
There was a problem hiding this comment.
If I already have the service enabled, does it still sleep for 60 seconds?
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5444 +/- ##
=======================================
Coverage 97.96% 97.96%
=======================================
Files 221 221
Lines 51496 51496
=======================================
Hits 50448 50448
Misses 1048 1048 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Two trade-offs regarding this delay:
Yes if |
dbolduc
left a comment
dbolduc
left a comment
There was a problem hiding this comment.
Yes if
time_sleepis not recorded in the state file (local or remote).
I am fine with this. It only gets added once.
| # Service enablement can take time to propagate. | ||
| resource "time_sleep" "wait_for_services" { | ||
| create_duration = "60s" | ||
| depends_on = [module.services] |
There was a problem hiding this comment.
Apparently we want to use triggers to have this sleep take affect when the services change. depends_on alone doesn't do that, it just controls the order of operations.
https://registry.terraform.io/providers/hashicorp/time/latest/docs/resources/sleep#triggers-usage
|
Can we wrap up this PR one way or another? |
|
I just added triggers to the sleep to make sure the 60s sleep only takes effect when we have newly enabled services. Re the tradeoff: I agree with @dbolduc that a one-time delay on a fresh project setup is a minor cost, so it’s a small compromise. Let me know how you feel about merging this. |
3 participants
To prevent flakes of
services not enabledimmediately after activation, I'm proposing to add atime_sleepdelay of 60 seconds.As noted in the Official Google Provider Guide, GCP APIs often return success at the global control plane before propagation to regional infrastructure is complete. This delay ensures resources like Firestore and KMS create successfully on the first run.
For reference, this pattern is also used in the official Google Cloud Datastore Module example, where they use a 120-second delay to make sure App Engine applications are initialized before creating indexes.